A wide variety of fault-tolerant, highly available, and other computer systems and data-storage systems rely on storing one or more redundant copies of each stored data object in one or more discrete component systems so that, in the event of a failure that destroys, corrupts, or makes unavailable one copy of a redundantly stored data object, another data-object copy can be used both for executing data-retrieval operations as well as to restore the destroyed, corrupted, or unavailable stored data object. Often, each data object within a large collection of data objects, such as a file system or database, is stored, on a primary component computer system or data-storage system, in a primary data-storage volume and is stored, on a second component computer system or data-storage system, in a secondary data-storage volume that is either equivalent to, or a mirror copy of, the primary data-storage volume.
The second component computer system or data-storage system, referred to below as the “second component system,” is generally interconnected with the primary computer system or data-storage system, referred to below as the “primary component system,” by one or more communications media collectively referred to, in the following discussion, as a “communications link.” In general, remote host or client computers or primary-system-resident clients issue WRITE, UPDATE, and other data-altering requests, collectively referred to as WRITE requests in the following discussion, to the primary component system. The primary component system executes the WRITE requests by writing data received in the WRITE requests to the primary volume within, or associated with, the primary component system. In addition to locally executing the WRITE requests, the primary component system forwards the received WRITE requests to the second component system for execution to the secondary volume. In certain systems, a two-phase commit protocol, or other such protocol, is used to ensure that WRITE requests executed to the primary volume are not committed until the WRITE requests forwarded to the second component system have been successfully executed to the secondary volume. In other systems, WRITE-request execution to the primary volume is allowed to proceed in advance of successful WRITE-request execution to the remote secondary volume. In either case, provision is generally made for circumstances in which the link between the first component system and the second component system fails.
In one commonly implemented technique in currently available fault-tolerant, highly available, and other computer systems and data-storage systems, a journal for WRITE requests is maintained by the first computer system or data-storage system. All received WRITES are buffered in the journal until notice is received from the second computer system or data-storage system that the WRITE or update operations have been successfully executed on the second computer system or data-storage system. When the communication link fails, WRITE requests accumulate in the journal. When the link is restored, the WRITE requests buffered within the journal are unspooled and issued in order to the second computer system or data-storage system for execution in an operation referred to as “resynchronization.” Once resynchronization has completed, and the contents of the primary volume and secondary volume are equivalent and up-to-date, normal operation of the system continues. In cases where the link remains inoperative for extended periods of time, and in which the system needs to continue to receive and execute WRITE requests from host or client computers, the journal may become completely filled. In these cases, WRITE operations may be executed locally to the primary volume, and a track-based bitmap may be maintained to indicate which tracks of the primary volume have been altered since the last point in time at which the primary volume and secondary volume were in equivalent data states. Upon restoration of the communications link, a bitmap-based resynchronization operation can be undertaken to resynchronize the primary volume with the remote secondary volume in which those tracks that are indicated to be altered are sent, generally out-of-order with respect to the order in which they were received, from the primary component system to the second component system.
Although journal-based resynchronization has proved to be an effective technique for allowing a computer system or data-storage system to continue to operate following a communications-link failure, and to resynchronize the primary volume and secondary volume following communications-link restoration, journal-based resynchronization may, in certain cases, involve significant resynchronization computational and communications overhead and delay, particularly in cases in which the journal has been filled, and the computer system or data-storage system resorts to track-based bitmap journaling. For these reasons, designers and manufacturers of fault-tolerant and/or highly available computer systems and data-storage systems have recognized the need for more efficient resynchronization operations to minimize computational and communications overhead and delay associated with resynchronization.